Open topic with navigation

Luminaire Manager - About Luminaire Families

A difficult situation we have faced in the development of ElumTools is the lack of a solid specification for the construction of Luminaire Families. In a perfect world, all possibilities could be handled by ElumTools transparently. However, the fact is we are bound by certain limitations of Revit and the logical demands of our own calculation engine. The result: ElumTools expects luminaire families to be well-formed geometrically and be photometrically correct. What do these phrases mean?

As the luminaire families that are currently available have been created by a variety of sources, following different methodologies (some of which never intended the family to be used for accurate lighting computations), you will inevitably find some families that require modification to function properly with ElumTools. We expect many current incompatibilities to progressively disappear as content creators begin to standardize on industry best practices. You may find that some families are easily modified on the user level while others leave more to be desired. Poorly formed families should always be referred back to the content creator.

Be sure and watch our YouTube videos on Luminaire Manager.

Family Creation Guidelines

1. All source types must be "Photometric Web" type. They cannot be fictitious such as "Spherical", "Hemispherical" or "Spot".
2. Set the "Emit Shape" to "Circle" for round luminous openings and to "Rectangle" for luminous rectangles. This will enable easy specification of the luminaires luminous area in Luminaire Manager's Light Source Tab for visualization purposes.
3. Each source should be combined with its corresponding housing geometry in the same lighting fixture family. ElumTools will ignore the luminaire housing geometry in the same family as the source when performing the initial direct lighting calculations. See "Nesting" below for more complicated families.
4. It is recommended that families be created as "Face-based" to be compatible with linked models. Face-based families are created (and appear) upside down as the family editor does not differentiate between items that sit on a floor, mount to a wall, ceiling or any other "face".
5. Families should be created with geometry that would normally be touching the host "face", congruent with the face surface. For example: mounting hardware for suspended luminaires are mounted on the face. Recessed luminaires should be recessed in the face.
6. The light source should generally be placed at the center of the luminous surface horizontally, and then depending on the light distribution, the vertical position should be: at the bottom of the luminous area for direct only; at the center of the luminous box for direct/indirect; and at the top of the luminous area for indirect only. Be very careful that you understand the luminaire test position so that you align the source correctly with the housing.

7. Previous versions of ElumTools had a few limitations with regard to correctly detecting the Revit light source position (especially with regard to dynamic/nested families). Currently ElumTools can properly detect the light source position for dynamic and nested families with no issues or difficult workarounds.

8. All housing geometry should be assigned a material type.
   1. It is preferred that material names be assigned containing the suppliers name and material description.
   2. For best results when rendering luminaire families in ElumTools, create a separate material for luminous surfaces and include the string "Light Source" in the material name (e.g. Manufacturer XYZ Light Source). See "Luminous Area" in the Light Source tab documentation.
9. Pendants and mounting brackets should be placed in a Shared, Nested, child family if they should occlude light from the luminaire. Otherwise, they should be placed in the parent family, or a non-shared child family (See Simple vs Nested Luminaire Families for details).

Simple vs Nested Luminaire Families

A luminaire family that requires more complexity must use nesting where the parent luminaire family hosts one or more child family instances. Examples include families with multiple sources such as track lighting, a chandelier, or complex mounting hardware that is NOT included in the luminaire photometric test data and therefore should occlude light. Nesting is complicated and it is unlikely we have all the possibilities covered in this brief analysis, however, the following rules should help you avoid costly errors and ensure ElumTools compatibility.

• Family geometry (assumed to be part of the luminaire housing) will not occlude its own source (source in same family).

• If the source is in a shared child family, you will be able to interact with it just like a non-nested source (i.e. you can prorate it, change the LLF, color, etc).

• If the source is in a non-shared child family, the source cannot be edited (LLF, color, proration, etc). ElumTools will detect and use the light source as it is specified in the child family.

• Child families which are shared will schedule separately which may or may not be desirable.
• Parent geometry will occlude sources from shared child luminaire instances.
• Parent geometry will not occlude sources from non-shared child luminaire instances.
• The geometry of each shared child luminaire family will not occlude its own source, but will occlude all other sources.

• The geometry of non-shared child luminaire families will not occlude its own source, the source of the parent family (if any), nor the source of any other non-shared child family, but will occlude all other sources.

• It is usually best practice to not "share" nested/child family geometry.
  • Non-shared child families cannot be scheduled separately.
  • Non-shared child families will act as part of the parent family and will not occlude a parent source.
  • Child families that contain only geometry (no light source) should not be shared unless you want them to occlude/reflect direct light from the parent family's source.

Comments on Shared Parameters and Type Catalogs

• ElumTools ignores the “initial intensity” parameters (wattage, efficacy, luminous flux, luminous intensity, illuminance) as this information is arbitrary and not physically accurate. All the information ElumTools needs is contained in the IES photometric file. This is inherently more accurate due the photometry being the result of a laboratory test.
  

• Coefficient of Utilization (CU) should not be cataloged in type catalogs as it is an instance parameter. More importantly, this parameter should be calculated by Revit MEP (based on the space where the luminaire resides) or overridden by the lighting designer.

   

• Light Loss Factors should not be cataloged in type catalogs. They should be determined by the lighting designer when considering the maintenance schedule of each project and the specific use case of the luminaires within each project.

• Ballast Factor (BF) should be specified in the corresponding IES file, and then, if necessary, cataloged in the type catalog. ElumTools automatically handles the BF parameter and reconciles it with the BF from the IES file. Our recommendation is to exclude all Light Loss Factors from type catalogs.

• As of this writing, you cannot specify photometry directly via a type catalog. This is a limitation of Revit. Note: You can specify the Photometric Web File parameter (i.e. the name of the photometric file), but there is no (visible) parameter in Revit to specify the Photometric Web File data.

ElumTools copyright 2018 Lighting Analysts, Inc.